Remove the check_msaa system that panicked when an OIT camera had
MSAA enabled, and make the OIT resolve pass MSAA-compatible. This
is really basic support and has artifacts on triangle edges.

With MSAA, the fragment shader runs once per triangle covering any
sample of a pixel, so pixels on shared mesh edges get one OIT fragment
per adjacent triangle. The OIT buffers store fragments per
pixel, not per sample, so both invocations blended at full coverage,
double-blending the surface along every interior triangle edge and
drawing a visible wireframe pattern on smooth meshes. Or something like
that.

This fixes it, with an API change to oit_draw.
oit_draw now always takes the @Builtin(sample_mask) fragment input.

Each OitFragmentNode stores the sample_mask. Node size increases from 12
-> 16 bytes, +33% memory use on the nodes buffer. The resolve shader takes
@Builtin(sample_index), which forces it to run at sample rate. Each
sample walks the pixel's list compositing only fragments that cover it,
and hardware MSAA averages the results.

Adjacent triangles now composite exactly at any alpha with antialiasing.
As long as you aren't stacking too many transparent triangles to be
sorted correctly. I only tested this with a backport to bevy 17, and
overflowing the sort brings about some kind of mismatch in the order
between two samples which can appear as visible mesh edges again.
Nevertheless this works a lot of the time.

The cost is MSAA 4 -> ~4x resolve pass invocations, which are expensive.
Takes up more lanes. It's up to the user. We could make it zero cost
for Msaa::Off by compiling in a different OitFragmentNode type.

With a depth prepass provided, oit_draw tested prepass_depth at sample 0
and culled the whole fragment on failure. That's obviously no good under
MSAA. A fragment might be occluded at only some of the samples. We can describe
this with a reduced sample mask, so we test each sample for prepass
depth and clear the bits that are occluded.